The present invention relates to the field of architecture design of data processing devices. More specifically, the invention is dealing with architecture design and functionality issues of register files used inside data processing devices.
The term xe2x80x98data processing devicexe2x80x99 has a very broad meaning and stands for terms like microprocessor, central processing unit (CPU), digital signal processor (DSP), application specific integrated circuit (ASIC), application specific standard product (ASSP), application specific instruction set processor (ASIP). The term xe2x80x98register filexe2x80x99 has the same meaning as used throughout the literature and is intimately related to the terms xe2x80x98microprocessorxe2x80x99, xe2x80x98CPUxe2x80x99 and xe2x80x98DSPxe2x80x99. A register file represents an important building block of a data processing device (microprocessor, CPU, DSP). It comprises a set of registers used to store intermediate computation results as well as to store data loaded from memory/cache. Usually, a register file has one or more read and write ports as well as one or more read and write address ports. The write/read address ports determine the registers to/from which data are written/read respectively. A complete description of usual (conventional) register files is given in section 3. As mentioned before, the present invention is dealing with architecture design and functionality issues of register files. Although the scope of the present invention is independent of any specific register-transfer level architecture and implementation of a register file, the description of the drawings in section 4 will rely on a specific register-transfer level architecture, this with the goal to ease the explanation of the exact functionality of such a register file.
The register-transfer level architecture of a register file can be thought of as consisting of a limited number of elementary building blocks with which the register file is built up. It typically comprises registers, crossbars and multiplexers as address logic. The register-transfer level architecture of a register file is an equivalent graphical representation of the functionality of a register file. Furthermore, the functionality of a register file can be exactly deduced from a given register-transfer level architecture. Therefore, the register-transfer level architecture is a convenient means to explain the functionality of a register file. Usually, implementation details like amplifiers, buffers, latches and registers which might be inserted between or inside elementary building blocks, are not considered as being relevant for the register-transfer level architecture since, although they may change the timing (due to the insertion of buffers, latches and registers), they do not change the functionality. Follows some terminology concerning crossbars. A crossbar is a building block that makes connections between its data inputs and data outputs via the signals which are applied to the control inputs of the crossbar. A fully connected crossbar is able to connect any data input to one, more or even all data outputs. A partially connected crossbar is able to connect any data input to one or more but not all data outputs. Multiplexers/demultiplexers are crossbars with one data input output and one or more data outputs/inputs respectively.
In all the figures that follow, arrows represent either bussed connections between building blocks or between bussed inputs and bussed outputs of building blocks, where the bus width of a bussed connection or of a bussed input and output is equal to one or more bits.
In the following sections, it is assumed that all mentioned ports and inputs are driven by digital signals having a finite set of possible values, this set usually comprising at least logical xe2x80x980xe2x80x99, logical xe2x80x981xe2x80x99 and high impedance xe2x80x98Zxe2x80x99.
FIG. 1 shows the register transfer level architecture of a xe2x80x98conventionalxe2x80x99 register file as based on the prior art and which contains several data read and data write ports. The data write ports are connected to the data inputs of a crossbar whose data outputs are connected to the data inputs of the registers of the register file. The data outputs of the registers are connected to the data inputs of a second crossbar whose data outputs are connected to the data read ports of the register file. The connections made by the two crossbars are controlled by the address signals applied to the write and read address ports, the write and read address ports being connected to the control inputs of said crossbars. In this way, the values applied to the write address ports determine the registers whose contents are going to be (over)written with the values applied to the data write ports of the register file whereas the values applied to the read address ports determine the registers whose contents are going to be read out via the data read ports. Normally, there are as many read and write address ports as there are data read and write ports of the register file. Furthermore, to each read port and each write address port is normally associated one data read and one write port respectively. Usually, as many register contents can be read simultaneously as there are data read ports. The same holds true for the write address ports data and write ports, with the exception that it is normally forbidden that two write address ports specify the same register to be written with two different values. Finally, it should be noted that normally register files have a clock input which is connected to the clock input of the registers of the register file. It means that the writing or reading of a specific register content happens either on the falling or on the rising edge of said clock signal. In other words the registers are clocked either on the falling or rising clock edge of said clock signal while the read and write address signals applied to the read and write address ports as well as the values applied to the write ports must be valid on the rising or falling clock edge.
A major drawback of such a conventional register file is that it does not support register renaming by itself. Register renaming is required to increase instruction level parallelism in order to achieve higher data processing rates and performance without deteriorating the utilization of the register file. Therefore, with such a conventional register file register renaming is only possible with additional hardware circuitry doing dynamic register (re)allocation and scheduling. This however implies higher power consumption as well as higher implementation and production costs.
The configurable register file as based on the present invention allows to solve this problem by inherently performing register renaming with only a small hardware overhead.
The present invention concerns a register file of a data processing device (microprocessor, DSP, CPU) according to claim 1.